\subsection{Economics and Incentive Layer}\label{sec:economics}

Polkadot will have a native token called DOT. Its various functions are described in this section.


\subsubsection{Staking rewards and inflation}\label{sec:inflation}

We start with a description of staking rewards, i.e.~payments to \emph{stakers} -- validators and nominators -- 
coming from the minting of new DOTs. 
Unlike some other blockchain protocols, the amount of tokens in Polkadot will not be bounded by an absolute constant, but there will rather be a controlled yearly inflation rate. Indeed, recent research~\cite{chitra2019competitive} suggests that in a proof-of-stake based protocol the staking rewards must remain competitive, in order to maintain high staking rates and high security levels, so deflationary policies are advised against. 

In our design, staking rewards are the only mechanism that mints DOTs. 
%Dots minted for staking rewards are the main driver of inflation in the system. This is because Treasury (Section \ref{sec:governance}), which receives a fraction of all transaction fees, slashings and missed validator rewards, has a mechanism design to closely matches its expenditure to its income, and thus is neither a net burner not net minter of Dots. 
Thus, it is convenient to introduce our inflation model in this section as well. 
%We do not consider rewards coming from transaction fees, slashings, nor rewards to fishermen and other reporters of offenses; these will be analyzed in further sections. 

Recall from the description of the NPoS protocol (Section \ref{sec:validators}) that both validators and nominators stake DOTs. 
They get paid roughly proportional to their stake, but can be slashed up to $100\%$ in case of a misconduct. 
Even though they are actively engaged for only one era%
\footnote{Recall that an era lasts approximately one day. See Table~\ref{t:time} in the Appendix.} 
at a time, they can continue to be engaged for an unlimited number of eras. 
During this period their stake is locked, meaning it cannot be spent, and it remains locked for several weeks after their last active era, to keep stakers liable to slashing even if an offence is detected late.

\paragraph{Staking rate, interest rate, inflation rate:} Let the staking rate be the total amount of DOTs 
currently staked by validators and nominators, divided by the current total DOT supply. 
The stakers' average interest rate will be a function of the staking rate: 
if the staking rate dips below a certain target value selected by governance, 
the average interest rate is increased, thus incentivising more participation in NPoS, and vice versa. 
For instance, a target staking rate of $50\%$ could be selected as a middle ground between security and liquidity. 
If the stakers' average yearly interest rate is then set to $20\%$ at that level, 
we can expect the inflation rate to fluctuate closely around $50\%\times 20\% = 10\%$. 
Hence, by setting targets for the staking rate and stakers' interest rate, we also control the inflation rate. 
Following this principle, every era we adjust our estimate of the staking rate, 
and use it to compute the total amount of DOTs to be paid to stakers for that era.

\paragraph{Rewards across validator supports:} 
Once the total payout for the current era is computed, we need to establish how it is distributed.
Recall that the validator election protocol (Section \ref{sec:validators}) partitions the active stake into 
\emph{validator supports}, where each validator support is composed of the full stake of one validator 
plus a fraction of the stake of its backing nominators, and this partition is made so as to make validator supports 
as high and evenly distributed as possible, hence ensuring security and decentralisation. 
A further incentive mechanism put in place to ensure decentralisation over time 
is paying validator supports equally for equal work, regardless of their stake. 
As a consequence, if a popular validator has a high support, its nominators will likely be paid less per staked DOT 
than nominators backing a less popular validator. Hence, nominators will be incentivised to change their preferences 
over time in favour of less popular validators (with good reputation nonetheless), helping the system converge to the ideal case where all validator supports have equal stake.

In particular, we devise a point system in which validators accumulate points for each payable action performed, 
and at the end of each era validator slots are rewarded proportional to their points. 
This ensures that validators are always incentivised to maintain high performance and responsiveness. 
Payable actions in Polkadot include: a) validating a parachain block, 
b) producing a relay chain block in BABE, 
c) adding to a BABE block a reference to a previously unreferenced uncle block,%
\footnote{In the BABE protocol, at times two block producers may generate different blocks A and B at the same height, leading to a temporary fork in the relay chain. The fork will quickly be resolved and one of the blocks selected, say A, as part of the main chain, while block B becomes an \emph{uncle} to all descendents of A. For security reasons, it is convenient to record and timestamp \emph{all} blocks produced, but since uncle blocks cannot be accessed via parent relations, we encourage block producers to explicitly add these references to the main chain.}
 and d) producing an uncle block.

\paragraph{Rewards within a validator slot:} As a nominator's stake is typically split among several validator supports, 
their payout in an era corresponds to the sum of their payouts relative to each of these supports. 
Within a validator support, the payment is as follows: 
First, the validator is paid a \emph{commission fee}, which is an amount intended to cover its operational costs. 
Then, the remainder is shared among all stakers -- both validator and nominators -- proportional to their stake. 
Thus, the validator receives two separate rewards: a fee for running a node, and a payout for staking. 
We remark that the commission fee is up to each validator to set, and must be publicly announced in advance. 
A higher fee translates to a higher total payout for the validator, and lower payouts to its nominators, 
so nominators will generally prefer to back validators will lower fees, and the market regulates itself in this regard. 
Validators who have built a strong reputation of reliability and performance 
will however be able to charge a higher commission fee, which is fair.

\medskip

We finalise the section with some observations on the incentives that our payout scheme is expected to cause on stakers. 
First, as validators are well remunerated and their number is limited, 
they have an incentive to ensure high backing levels from nominators to ensure getting elected, 
and thus they will value their reputation. Over time, we expect elections to be highly competitive 
and for elected validators to have strong track records of performance and reliability and large stake backings.
Second, even if payouts across different validator supports are independent of their stake, 
within a validator support each actor is paid proportional to their stake, 
so there is always an individual incentive to increase one's own stake. 
Finally, if a validator gains a particularly high level of backing, it can profit from it by either increasing 
its commission fee, which has the effect of raising its own reward at the risk of losing some nominations, 
or launching a new node as a validator candidate and splitting its backing among all its nodes. 
On this last point, we welcome operators with multiple validator nodes, 
and even aim to make their logistics simpler. 
%, so long as they disclose such correlations 
%so that nominators can adjust their strategy accordingly.


\subsubsection{Relay-chain block limits and transaction fees}

\paragraph{Limits on resource usage:} We bound the amount of transactions that a relay-chain block can process, 
in order to a) ensure that each block can be processed efficiently even on less powerful nodes and avoid delays in block production, and b) have guaranteed availability for a certain amount of high-priority, operational transactions such as misconduct reports, even when there is high network traffic. 
In particular, we set block constraints on the following resources: on-chain byte-length, 
and time and memory required to process the transactions.

We classify transactions into several types, according to their priority level and resource consumption profile. 
For each of these types we have run tests based on worst-case scenarios for state, and for different input arguments. 
From these tests, we establish conservative estimates on resource usage for each transaction, and we use these estimates to ensure that all constraints on resource usage are observed.

We also add an extra constraint on resources: we distinguish between regular and high-priority transactions, and only let regular transactions account for up to $75\%$ of each block resource limit. This is to ensure that each block has a guaranteed space for high-priority transactions of at least $25\%$ of resources.

\paragraph{Transaction fees:} We use the model described above to set the fee level of a transaction based on three parameters: its type, its on-chain length, and its expected resource usage. This fee differentiation is used to reflect the different costs that a transaction incurs on the network and on the state, and to encourage the processing of certain types of transactions over others. A fraction of every transaction fee is paid to the block producer, while another fraction goes to finance the Treasury (Section~\ref{sec:treasury}). We highlight that, for a block producer, the rewards coming from transaction fees may constitute only a small fraction of their overall revenue, just enough to incentivise inclusion on the block.

We also run an adaptive transaction fee schedule that reacts to the traffic level, and ensures that blocks are typically far from full, so that peaks of activity can be dealt with effectively and long inclusion times are rare. In particular, the fee of each transaction is multiplied by a parameter that evolves over time depending on the current network traffic. 

 

We make fees evolve slowly enough, so that the fee of any transaction can be predicted accurately within a frame of an hour. In particular, we do not intend for transaction fees to be the main source of income for stakers.



%\subsubsection{Slashing}
